home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 174 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  2.1 KB
  1. Path: seaeagle.csi.cam.ac.uk!ag129
  2. From: ag129@ucs.cam.ac.uk (A. Grant)
  3. Newsgroups: comp.std.c
  4. Subject: What does "implementation-defined" mean?
  5. Date: Wed, 24 Jan 1996 13:20:37
  6. Organization: University of Cambridge
  7. Message-ID: <ag129.47.000D585E@ucs.cam.ac.uk>
  8. NNTP-Posting-Host: seaeagle.csi.cam.ac.uk
  9.  
  10. 1.6:
  11.   "Implementation-defined behaviour - behaviour, for a correct program
  12.    construct and correct data, that depends on the characteristics of
  13.    the implementation and that each implementation shall document."
  14.  
  15. My question is, what form must the documentation take?  Does it need
  16. to be intelligible and useful?  For example,
  17.  
  18. 3.5.2.1:
  19.   "Whether the high-order bit position of a 'plain' int bit-field is
  20.    treated as a sign bit is implementation-defined. ...
  21.    If insufficient space remains, whether a bit-field that does not fit
  22.    is put into the next unit or overlaps adjacent units is 
  23.    implementation-defined.  The order of allocation of bit-fields 
  24.    within a unit (high-order to low-order or low-order to high-order) 
  25.    is implementation-defined."
  26.  
  27. There are 2 x 2 x 2 obvious possibilities here.  However an 
  28. implementation might want to do different things in different
  29. circumstances while still documenting its behaviour.  Perhaps the
  30. signedness of int bitfields depends on the number of bits.  The
  31. Standard seems to place no limits on the complexity of the 
  32. documentation or the form it must take, only that (somehow) a
  33. reader is supposed to be able to use it to determine the program's
  34. behaviour.  Surely this is unsatisfactory?
  35.  
  36. It would seem from 1.6 that the documentation of the behaviour can
  37. make reference only to the "program construct", i.e. in the case of 
  38. bitfields the behaviour depends at most on the surrounding 'struct' 
  39. and not on the program as a whole.  Is this a correct interpretation?
  40.  
  41. Why, given that the behaviour is required to be documented for the 
  42. human reader, does the Standard not require it to be documented for
  43. the program, e.g. by the compiler providing 
  44.   #define INT_BITFIELDS_ARE_SIGNED
  45. or
  46.   #define INT_BITFIELDS_ARE_UNSIGNED
  47. or 
  48.   #define INT_BITFIELDS_CAN_BE_EITHER_SIGNED_OR_UNSIGNED ?
  49.